-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix image_loader for animated image types #5688
Conversation
Side note: I think an even better way to handle this would be to not treat static webp/gif images as "animated". The webp spec has an "ANIM" chunk at a specific position in the headers if it is animated, which you could use to determine in addition to searching for the RIFF WEBP header. I'd be happy to help out with that if you'd like. Otherwise I thought I'd just bring it to your attention in case you haven't thought about that. |
@emilk Do you have any concerns with this approach? Without this, my images don't work with the custom image_loader. |
@@ -57,6 +58,7 @@ impl ImageLoader for ImageCrateLoader { | |||
// 1. URI extension (only done for files) | |||
// 2. Mime from `BytesPoll::Ready` | |||
// 3. image::guess_format (used internally by image::load_from_memory) | |||
let uri = decode_animated_image_uri(uri).map_or(uri, |(uri, _frame_index)| uri); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like it because I feel like the image loader shouldn't need to know about animated images. The culprit is here, but fixing it there would be a much bigger change so I think this fix is fine fow now.
In theory this should break urls like http://example.com/image.png#123, where the loader now would try to load http://example.com/image.png, but I these urls are very rare so this should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that's why I pointed out that we shouldn't even be treating the static webp images as animated (in is_animated_image_uri
). Would you like me to take a look at fixing that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, sorry, I didn't mean that I think this fix should be in is_animated_image_uri. I think it would be around are_animated_image_bytes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For fixing specifically webp, I would image something like this:
has_gif_magic_header(bytes) || (has_webp_header(bytes) && is_animated_webp_header(bytes))
I haven't looked into the gif spec to see if there is a similar header that we could look at for that.
Preview available at https://egui-pr-preview.github.io/pr/5688-master |
@lucasmerlin It looks like this PR is missing a label of some sort. I don't think I can add that, can I? |
No, unfortunately not, only maintainers can. We need the labels for proper changelog generation, thats why we have a pipeline for that |
Hi, after upgrading to 0.31.0 all of my beautiful static webp images started failing to load. I use the image_loader to load those via the
image
crate.I noticed that with 0.31.0 there are additions to how animated image types are handled with frames and such. And with those changes the frame index is attached to the uri at the end. This was problematic for the image_loader, because it wasn't updated to handle that frame tag at the end of the uri, so when looking up the bytes, it would fail to match the uri in the bytes cache (the bytes were being saved without the frame index, but attempting to be fetched with the frame index).
This fixes the image_loader for me with webp & gif. They don't load the animations, but I think that is because I don't have the custom image_loader set up so I'm not worried about that for myself. I'm not sure if that part is problematic in general, or if its just the way I have my features set up.
You can recreate the issue on master by swapping out the dependency features in the
images
example like this: